The aim of the testing was to evaluate the functions of the user interface that did not require to be connected to the server. Further testing, carried out as part of the integration stage detailed in chapter 7, would deal with testing relating to both the user interface and the network code. We performed this evaluation ourselves without the use of other users. Given that the system was not functioning (i.e., messages couldn't be sent), we felt that this was sufficient, as the only purpose of this testing was to check which of the implemented design features work as expected and we had the best knowledge of what has to be checked and what results were expected.

Within the login window, we needed to check if clicking on the registration button would display the registration window and if clicking on the cancel button would close the application. We also needed to check if clicking the submit button would trigger appropriate checks made before referring the user either to the main window or back to the login window. The checks that needed to be made include checking if the username was in the email format and that the password had more than three characters. At that stage, we could not check if the password matches the one specified for the username provided as this would require access to the database. If the data provided were acceptable the user would be sent to the main window, otherwise they would be sent back to the login window.

An issue highlighted during the above testing of the login/registration process was that if a login failed, the user would simply be ``bounced'' back to the login window. There was no information provided to them as to why their login was not successful, and from a usability perspective this is should not be the case. While this design issue was identified, it was not rectified at this stage.

Within the registration window, we again needed to check if the cancel button would refer the user back to the login window and if clicking the submit button would trigger a number of checks. The checks involved include checking if the username was in the email format, and if it matched the username provided in the confirm username input box. In addition, the system checks if the password provided matches the confirm password input box. If all of the submitted data was correct, the user should be sent back to the login page to allow them to login in to the system. Otherwise, the registration page should be shown again to allow the user to correct the information provided. 

Again, this testing revealed a lack of confirmation, and did not show the appropriate messages. For example, the user would be prompted to register again if they hadn't completed the form correctly in the first instance, but they would not be told why. Again, this is a usability problem.

Within the main window, we were unable to test the option to search for users in the database, to then add them to the contact list, without being connected to the server. However, there were a number of functions that we could test to some extent without connecting to the server. 

One such feature was using emoticons. We were to unable to see if emoticons are displayed correctly when sent over the network, but we successfully checked if the user can choose and see emoticons in the message window before sending and in the chat window after sending without getting errors. It should be noted that the user cannot see the image of the emoticon before sending, but a textual representation is given. This is an implementation detail, because the message input box is not capable of rendering HTML.

Similarly, we were not able to check if formatted text was displayed in the same format once sent over the network. We only made sure that all of the formatting option such us changing size, type and colour of the font worked and was displayed correctly to the user in both the message and the chat windows.

In addition, we tested if we could upload an avatar that will then be display as a small icon beside the display name of the user. The option to upload avatar worked properly resizing the picture to the required size before placing in it the space provided. However, we had no way of testing whether the avatar picture was displayed accordingly to all of the contacts of that user as this would require the server connection.

We came across the same issue when testing the ability to change status. A user could successfully choose and change his status and this was reflect in his window but there was no means of checking whether the status would change accordingly to all contacts of that user.

Even though we were unable to search for users in the database we tested our system to find if a given user was in the contact list. The user would type in another user’s username into the search box the system would print a message informing whether such user was in the contact list or not.

To summarise, although this was a very simple and informal way of testing the GUI but it allowed us to confirm what features of the interface worked correctly and what needed further implementation. A lot of the client interface couldn't be tested without using the server. Therefore, more testing was completed as part of the integration stage, which is detailed in chapter 7.
